The present invention relates, in general, to software programming systems and methods, and more specifically, to visual programming techniques for use with object-oriented software languages.
Software is increasingly becoming a major portion of cost associated with computer systems because it is very xe2x80x9clabor-intensive.xe2x80x9d Some of this cost is due to the effort involved in writing and debugging programs, other costs involve maintaining programs after they have been written. Accordingly, considerable effort has been expended in order to reduce the time and costs involved with writing, debugging and maintaining moderate and large software programs. Much of this effort has been related to developing programming languages and programming techniques which will allow programmers to build on or xe2x80x9creusexe2x80x9d programs and code segments that have been written by others.
Until very recently, software programming was heavily dominated by an approach referred to as xe2x80x9cstructured programming.xe2x80x9d Common software programming languages used in this approach were, and remain, BASIC, FORTRAN, and PASCAL. These are considered xe2x80x9chigher orderxe2x80x9d languages that are written in human readable code and ultimately translated into machine or computer readable code by a compiler. Typically, structured programs have consisted of a combination of defined variables of specific data types, e.g. integer, real, and character, and a complimentary set of functions or routines which operate on these variables. Often, a program would include sub-routines which are smaller routines within a program or larger routine that carry out certain operations, e.g. printing data in a given output format. The emphasis to this approach was inputsxe2x80x94functionsxe2x80x94outputs and they were often represented as flowcharts by the designers, which logically represented how the program functioned and branched into different functional paths. As an increasing number of programs became large (tens of thousands of lines of code and above) structured programs became increasingly complex and difficult to write, troubleshoot and maintain.
Flowcharts became unwieldy and the tracking of errors through permutations of variables, lengthy code, and a wide variety of program branches was time and cost intensive and often produced less than adequate results. Consequently, a new approach to software programming called Object-Oriented Design (OOD) or Object-Oriented Programming (OOP) emerged and has gained increasing popularity among software developers. OOP promised greater reuse and maintainability than its structured programming predecessor because of an emphasis on well-defined and self contained objects, rather than the structured programming emphasis on a proliferation of relatively loosely-related data manipulating functions and subroutines.
Object Oriented Programming techniques involve the definition, creation, use and destruction of xe2x80x9cobjects.xe2x80x9d These objects are software entities comprising data elements, or attributes, and methods, or functions, which manipulate the data elements. The attributes and related methods are treated by the software as an entity and can be created, used and destroyed as if they were a single item. Together, the attributes and methods enable objects to model virtually any real-world entity in terms of the entity""s characteristics, represented by the data elements, and the entity""s behavior, represented by data manipulation functions or methods. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.
Objects are defined by creating xe2x80x9cclassesxe2x80x9d which are not objects themselves, but which act as templates that instruct the computer how to construct the actual object. A class may, for example, specify the number and type of data variables and the steps involved in the methods which manipulate the object""s data. When an object-oriented program is compiled, the class code is compiled into the program, but no objects exist. Therefore, none of the variables or data structures in the compiled program exist or have any memory allotted to them. An object is actually created by the program at runtime by means of a special function called a xe2x80x9cconstructorxe2x80x9d which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct the object. Likewise, objects can be destroyed by a special function called a xe2x80x9cdestructorxe2x80x9d or can be destroyed by special programs called xe2x80x9cgarbage collectorsxe2x80x9d when no longer needed. Objects may be used by using their data and invoking their methods. When an object is created at runtime, memory is allotted and data structures are created.
The principle benefits of object-oriented programming techniques arise out of three basic principles; encapsulation, polymorphism and inheritance. Specifically, objects can be designed to hide, or encapsulate, all, or a portion of, the internal data structure and the internal methods. More-particularly, during program design, a program developer can define objects in which all or some of the attributes and all or some of the related methods are considered xe2x80x9cprivatexe2x80x9d or for use only by the object itself. Other data or methods can be declared xe2x80x9cpublicxe2x80x9d or available for use by other programs. Access to the private variables by other programs can be controlled by defining public methods for an object which access the object""s private data. The public methods form a controlled and consistent interface between the private data and the xe2x80x9coutsidexe2x80x9d world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.
Polymorphism is a concept which allows objects and functions which have the same overall format, but which work with different data, to function differently in order to produce consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, at runtime, the program will determine which of the three functions is actually called by examining the variable types. Polymorphism allows similar functions which produce analogous results to be xe2x80x9cgroupedxe2x80x9d in the program source code to produce a more logical and clear program flow.
The third principle which underlies object-oriented programming is inheritance, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes, and the objects which are. later created from them, as related. Specifically, classes may be designated as subclasses of other base classes. A subclass xe2x80x9cinheritsxe2x80x9d and has access to all of the public functions of its base classes just as if these functions appeared in the subclass. Alternatively, a subclass can override some or all of its inherited methods or may modify some or all of its inherited methods merely by defining a new method with the same form. Overriding or modification does not alter the method in the base class, but merely modifies the use of the method in the subclass. The creation of a new subclass which has some of the functionality, with selective modification, of another class allows software developers to easily customize existing code to meet their particular needs.
Object-Oriented Programming languages include C++ and Java, as well as other languages. Each language has an express or implied xe2x80x9cobject model.xe2x80x9d Generally speaking, an object model is a unifying set of rules that describe object structure, object life cycle, and inter-object communication. Object structure relates to the physical layout of objects in memory, while object life cycle refers to how applications create and destroy objects. Inter-object communication refers to protocols by which objects communicate with one another. Object models are useful in contexts where all objects in a given system need to conform to a given protocol governing these parameters. Most object-oriented and object-based languages, including the Java programming language, do not specify true object models, but merely specify syntax and semantics of a basic object implementation without specifying the actual rules that unify object systems. Some object-oriented languages also incorporate the notion of xe2x80x9ccomponentsxe2x80x9d which are self-contained objects that perform a specified function or procedure. Components have a pre-defined interface that conforms to the object model of the underlying language and generally conform to a xe2x80x9ccomponent modelxe2x80x9d associated with the language.
Initially, the promise of reusability and economy of OOP was not realized. Standards were not in place to insure interoperability of objects or cross-platform interoperability. This problem became even more evident when the Internet and the World Wide Web (Web) emerged as widely-used resources and ensured that a wide variety of platform configurations would attempt to access and use commonly-available information on the Internet. As a result, applications designed to operate on the Web used languages designed specifically for the Web, such as hyper-text mark-up language (HTML) as a way to provide a static, but commonly useable, form of coded information while object-oriented programming was applied in other applications. But the problem of cross-platform interoperability persisted and grew as it became more desirous to add dynamic capability to the Web and as many organizations were using multiple platforms and grappling with interoperability internally. Also, the proliferation of objects conforming to different object models prevented significant reuse, as originally envisioned.
Recently, along with the increased distribution of code among dissimilar systems for use, there has also been an increased desire for programmers to share code over a distributed system. A distributed system is one in which there are typically multiple computer systems accessing or sharing information among one another. Client-server systems, for example, are distributed computer systems. These various systems use a variety of persistent stores, e.g. ODBC, JDBC, and flat-file, and directory services, e.g. LDAP and URL. This variation in systems causes incompatibilities and inefficiencies in sharing code. Often times, programmers will have to modify code received from others in order to make it re-useable. This additional work tends to decrease code reuse and, even if reuse is attempted, stretch out the code development for new applications.
In order to solve these problems, a number of common object architectures were developed. These include the Common Object Request Broker Architecture (CORBA) and the Remote Method Invocation (RMI) system. The CORBA architecture includes an Interface Definition Language (IDL) which allows objects written in different languages to have standardized interfaces so that the objects will be able to communicate. CORBA and RMI also includes mechanisms for transporting communications between remotely-located objects which have interfaces that conform to their specifications. CORBA and RMI have allowed interoperability among objects written in various OOP languages and for use on various platforms.
In addition in order to using more efficient languages to reduce programming time, programming techniques have also been improved. Initially, program were written by typing lines of program statements. In the case of OOP programs, time was spent entering information with complicated syntax which was relatively standard from object to object. For example, for each constructor or method, a programmer normally wrote lines of code to marshal the data for each parameter of the method or constructor. The programmer then had to write a code line to call the method. In the case of methods, the programmer had to write code lines to capture and store the result of the method call. Finally, the programmer had to write code to deal with exceptions that occurred during the method call. This was tedious and led to a proliferation of typographical and spelling errors which increased the debugging time.
However, recently, xe2x80x9cvisual buildersxe2x80x9d are increasingly being used to expedite programming. A visual builder allows programs to be written with the help of a Graphical User Interface (GUI). Objects can be represented by icons which encapsulate the xe2x80x9cstandardxe2x80x9d portions of the code and allow program developers to create program code for objects by specifying the object properties and writing code for the object methods. The visual builder then generates the actual class code for the object, including the code for marshaling data and handling results and exceptions. Many visual builders contain predefined components which can be customized or used to derive other components. These predefined components are generally represented as icons on a xe2x80x9cpalettexe2x80x9d, to which new components can be added. A programmer using the visual builder manipulates these components on the screen, or xe2x80x9cin the active windowxe2x80x9d or xe2x80x9cworkspacexe2x80x9d, to create new components.
In some visual builders, the objects or components can also be linked by the programmer using the visual builder interface to create a unique program. As a result, it is not necessary, to some degree, for a visual programmer to spend as much time entering code and debugging minor mistakes as a typical software developer who must enter the code text directly.
Examples of visual builders are disclosed in U.S. Pat. No. 5,546,519 to Berry, which illustrates describes a system and method for the visual programming of iterator link objects using a standard visual builder, whereby the user need not know the programming language itself. Properties of objects are also editable, usually via pull-down menus, and new objects can be added to the visual builder palette, primarily as a function of the visual builder itself.
In U.S. Pat. No. 5,642,511 to Chow et. al., a system and method are described for implementing an improved visual builder which allows a program developer to manipulate a hierarchical tree used to represent an OOP program. In the Chow patent a xe2x80x9cproxyxe2x80x9d tree comprised of proxy objects is built by using a visual builder to copy and edit user selected objects, thereby creating a new program.
Visual builders are attractive because they help to reduce programming time. However, each object or component used in the visual builder must be built by customizing an existing visual builder class or by creating a new component xe2x80x9cfrom scratch.xe2x80x9d It would be desirable to be able to use existing objects and components, represented by textual program code, with such builders. To date, there is no automated way to create components which can be directly used in the builders from unparsed object-oriented class code statements. Therefore, in order to use objects created from such classes, a program developer must recreate the class or component with the builder by appropriately defining the properties and coding the methods.
Additionally, when components are created using a visual builder, it is desirable to test them within the visual builder application without creating objects from the components and incorporating them into applications. However, current visual builders do not allow the components to be tested in this efficient manner. Instead, they require an object to actually be constructed from the component before the object can be tested. If the object works, it is assumed that the component coding is correct. Once a component is tested and shown to operate correctly, then it can be safely incorporated in to a visual builder palette for use by other developers.
Consequently, a need exists for a method and apparatus for creating object oriented component, from existing object oriented text-based code. A need also exists for creating these components in accordance with defined object standards, e.g. CORBA and IDL. Furthermore, a need exists to create these components in such a manner that the newly-created components can be used with existing visual builders.
An inventive method and system convert text-based object-oriented class code, located in either local or remote machines into proxy components which can be used in existing visual builders. Proxy components are created from each method, including constructors, in the class code and encapsulate the parameters of the methods. For example, parameters associated with a method are represented by properties of the proxy component created from that method. These properties are visually editable and can be bound visually to other component properties using, for example, pull down menus in a visual builder. Exceptions which occur during operation of the method are treated as events and can be visually passed to other components.
In accordance with one embodiment, a universal transport application programming interface (API) provides a mechanism for manipulating objects in a xe2x80x9ccomponent-orientedxe2x80x9d manner on either local or remote platforms. Essentially, the universal transport API is an object request broker which is controlled by the proxy components and includes two transport implementations: one for local transport and one for remote transport. The local transport implementation allows access to local OOP code resident on a user""s computer. The remote transport implementation allows a user to access and use OOP classes resident on other computers, even if the classes do not conform to either the Remote Method Invocation (RMI) or the Common Object Request Broker Architecture (CORBA) specifications without manually wrapping the classes. Invocations of methods and constructors, and exceptions generated by the during the method invocations are each encapsulated into separate classes in a way which permits late binding and allows the invocation information to be serialized.
In accordance with another embodiment, a component-oriented compiler can parse any text-based OOP source code and create components for each of its public constructors and methods. The compiler retrieves all relevant entities, such as constructors, methods, fields, comments and parameter names. The parameters, fields, and properties of a constructor become the bound properties of the resultant constructor component. The parameters of a method become the bound properties of a method component. Finally, the method component includes a special bound property called xe2x80x9cresultxe2x80x9d which contains the result of a method event. The compiler compiles the code it generates, creates a manifest file, and includes all files in an archive file.
In accordance with yet another embodiment, a visual environment add-on (VEA) program operates with a standard visual builder to permit complex applications to be built without the need to include any extra programming steps to preserve exceptions or properties. The VEA program allows an OOP component, including those generated by the aforementioned compiler, to be placed on the existing palette of the visual builder so that the component can be manipulated by the visual builder to generate a component-based application.